home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / share / catman / u_man / cat1 / rtmond.z / rtmond
Text File  |  1998-10-30  |  15KB  |  264 lines
  1.  
  2.  
  3.  
  4. RRRRTTTTMMMMOOOONNNNDDDD((((1111))))                                                            RRRRTTTTMMMMOOOONNNNDDDD((((1111))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      rtmond  - system event monitoring daemon
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ////uuuussssrrrr////eeeettttcccc////rrrrttttmmmmoooonnnndddd [ _o_p_t_i_o_n_s ]
  13.  
  14. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  15.      rrrrttttmmmmoooonnnndddd is the server process that collects system and user events and
  16.      dispatches them to clients such as ppppaaaaddddcccc(1), WWWWiiiinnnnddddVVVViiiieeeewwww(1), and rrrrttttmmmmoooonnnn----
  17.      cccclllliiiieeeennnntttt(1).  In normal operation, _rrrr_tttt_mmmm_oooo_nnnn_dddd is atomatically started when the
  18.      system is booted.  Only one copy of rrrrttttmmmmoooonnnndddd can be started per machine.
  19.      When clients connect to rrrrttttmmmmoooonnnndddd and request event data, rrrrttttmmmmoooonnnndddd creates
  20.      additional children to collect event data from each CPU that event data
  21.      is being requested for (if such children are not already running) and one
  22.      more child to manage the transfer of the event data to the client.
  23.  
  24.  
  25. OOOOPPPPTTTTIIIIOOOONNNNSSSS
  26.      ----aaaa _a_c_c_e_s_s-_s_p_e_c
  27.                Use _a_c_c_e_s_s-_s_p_e_c to control all client accesses; overriding
  28.                anything given in the normal client access control file.  See
  29.                below for a description of the client access control mechanism.
  30.  
  31.      ----bbbb _i_o_b_u_f_s_i_z
  32.                Use _i_o_b_u_f_s_i_z when allocating buffers that hold event data that
  33.                is to be written to a client.  By default rrrrttttmmmmoooonnnndddd allocates up
  34.                to five 16 kilobyte buffers for each client, for each CPU on
  35.                which event data is collected.  See also the ----iiii option below.
  36.  
  37.      ----cccc        Enable the generation of checksums in event records transmitted
  38.                to clients.  Checksums are used for debugging data corruption
  39.                problems and should not be generally enabled as it slows down
  40.                the server; potentially causing events to be lost.
  41.  
  42.      ----dddd        Do not detach from the controlling terminal and direct all
  43.                diagnostic messages to the standard error descriptor.  By
  44.                default rrrrttttmmmmoooonnnndddd detaches itself from the controlling terminal
  45.                and directs all diagnostic messages to the ssssyyyyssssllllooooggggdddd(1M) service.
  46.                This option is useful when debugging the server.
  47.  
  48.      ----ffff _a_c_c_e_s_s-_f_i_l_e
  49.                Take client access control information from _a_c_c_e_s_s-_f_i_l_e.  By
  50.                default rrrrttttmmmmoooonnnndddd looks for client access control information in
  51.                the file ////eeeettttcccc////rrrrttttmmmmoooonnnndddd.
  52.  
  53.      ----iiii _m_a_x_i_o_b_u_f_s
  54.                Use _m_a_x_i_o_b_u_f_s as the upper bound on the number of buffers
  55.                allocated for holding event data that is to be written to a
  56.                client.  By default rrrrttttmmmmoooonnnndddd allocates up to five buffers for
  57.                each client, for each CPU on which event data is collected.
  58.                See also the ----bbbb option above.
  59.  
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. RRRRTTTTMMMMOOOONNNNDDDD((((1111))))                                                            RRRRTTTTMMMMOOOONNNNDDDD((((1111))))
  71.  
  72.  
  73.  
  74.      ----llll        Force the server process and event collection threads to lock
  75.                themselves in memory.  When this is specified rrrrttttmmmmoooonnnndddd uses the
  76.                pppplllloooocccckkkk(2) system call to lock its text and data segments into
  77.                memory.  This option may be useful if rrrrttttmmmmoooonnnndddd is losing events
  78.                because it is paged or swapped out of memory.  Beware however
  79.                that on large multiprocessor systems this may cause lots of
  80.                locked-down memory to be requested, which may not be possible.
  81.  
  82.      ----pppp _p_r_i_o_r_i_t_y
  83.                Use _p_r_i_o_r_i_t_y to set the scheduling priority for the server and
  84.                each event collection thread spawned by the server.  By default
  85.                rrrrttttmmmmoooonnnndddd uses a realtime scheduling priority of 88; this option
  86.                can be used to specify an alternate non-degrading priority.
  87.  
  88.      ----PPPP _p_o_r_t   Use _p_o_r_t for the TCP port number on which client connections
  89.                are received.  By default rrrrttttmmmmoooonnnndddd uses the port number
  90.                associated with the ``rtmon'' service; otherwise falling back
  91.                to port 1455.
  92.  
  93.      ----qqqq _q_u_i_e_t_t_i_m_e
  94.                Use _q_u_i_e_t_t_i_m_e for the time interval for issuing ``null
  95.                records'' to clients (specified in milliseconds).  A null
  96.                record is sent to a client when there has been no data for a
  97.                CPU for an extended period of time.  This mechansim assists
  98.                clients in merging event data streams from multiple CPUs.  By
  99.                default rrrrttttmmmmoooonnnndddd uses a 200 millisecond quiet time interval.
  100.  
  101.      ----tttt _t_r_a_c_e-_m_a_s_k
  102.                Enable diagnostic tracing messages in the areas specified by
  103.                _t_r_a_c_e-_m_a_s_k.  Tracing messages are broken up into areas that are
  104.                identified symbolically by the following:
  105.  
  106.                NNNNaaaammmmeeee          DDDDeeeessssccccrrrriiiippppttttiiiioooonnnn
  107.                access        Client access control operations
  108.                all           All tracing facilities
  109.                client        Client data connection setup and teardown
  110.                debug         Miscellaneous information for debugging
  111.                eventio       Client event data write operations
  112.                events        Event collection low-level operations
  113.                lostevents    Kernel lost event actions
  114.                none          No events (for disabling tracing)
  115.                perf          Client performance statistics
  116.                kid           Process/thread ID cache management
  117.                rpc           Client-server protocol
  118.                sync          Time synchronization work
  119.                thread        Event collection thread operations
  120.                tstamp        Kernel tstamp operations
  121.  
  122.                Area names are case insensitive.  To trace multiple areas
  123.                combine the names with ``,'', ``|'', or ``+''.  To exclude
  124.                areas use a ``-'' as a separator; e.g. ``all-tstamp-eventio''.
  125.                Beware that tracing some areas of operation can result in
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. RRRRTTTTMMMMOOOONNNNDDDD((((1111))))                                                            RRRRTTTTMMMMOOOONNNNDDDD((((1111))))
  137.  
  138.  
  139.  
  140.                events being lost; the ``events'' area is an example.
  141.  
  142.                By default rrrrttttmmmmoooonnnndddd does not emit any trace messages.  ``perf''
  143.                messages are always emitted if client events are lost in order
  144.                to provide a log to check against problem reports.
  145.  
  146.      ----UUUU _p_a_t_h_n_a_m_e
  147.                Use _p_a_t_h_n_a_m_e for the name of the UNIX domain socket on which
  148.                client connections are received.  By default rrrrttttmmmmoooonnnndddd listens for
  149.                connections on a socket bound to the pathname
  150.                ////ttttmmmmpppp////....rrrrttttmmmmoooonnnndddd____ssssoooocccckkkkeeeetttt.
  151.  
  152.      ----wwww _w_a_i_t_t_i_m_e
  153.                Use _w_a_i_t_t_i_m_e for the time threshold for waiting for the system
  154.                event queue to reach the low water mark (specified in
  155.                milliseconds).  While rrrrttttmmmmoooonnnndddd is waiting for the system event
  156.                queue to fill up it blocks and is incapable of processing
  157.                events from applications.  Consequently this time value
  158.                controls the maximum delay for a user-level event to be
  159.                dispatched to interested clients.  By default rrrrttttmmmmoooonnnndddd uses a
  160.                waittime of 100 milliseconds.
  161.  
  162.      ----zzzz        Enable system call tracing for all the event collection threads
  163.                rrrrttttmmmmoooonnnndddd spawns.  By default rrrrttttmmmmoooonnnndddd disallows system call tracing
  164.                on the event collection threads to avoid loading the system.
  165.                if this option is specified then global system call tracing
  166.                will include system calls done by these threads.  It is
  167.                recommended that this option be used only for debugging rrrrttttmmmmoooonnnndddd.
  168.  
  169. EEEEVVVVEEEENNNNTTTT MMMMAAAASSSSKKKKSSSS
  170.      An _e_v_e_n_t _m_a_s_k specifies a set of events; either the set of events that a
  171.      client may request be collected, or possibly the set of events to be
  172.      collected on behalf of a WindView client.  An event mask is specified as
  173.      a set of _e_v_e_n_t _c_l_a_s_s_e_s with each class specified symbolically as one of
  174.      the following:
  175.  
  176.      NNNNaaaammmmeeee        DDDDeeeessssccccrrrriiiippppttttiiiioooonnnn
  177.      all         All events
  178.      alloc       Memory allocation
  179.      disk        Disk i/o work
  180.      intr        Hardware interrupts
  181.      io          I/O-related events (disk+intr)
  182.      netflow     Network I/O flow
  183.      netsched    Network I/O scheduling
  184.      network     Network-related events (netflow+netsched)
  185.      none        No events
  186.      profile     Kernel profiling
  187.      scheduler   Process and thread scheduler
  188.      signal      Signal delivery and reception
  189.      syscall     System calls and their arguments
  190.      task        Process and thread scheduling
  191.      vm          Virtual memory operation
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. RRRRTTTTMMMMOOOONNNNDDDD((((1111))))                                                            RRRRTTTTMMMMOOOONNNNDDDD((((1111))))
  203.  
  204.  
  205.  
  206.      Event class names are case insensitive; i.e. ``SIGNAL'' is interpreted
  207.      the same as ``signal''.  Multiple event classes may be included by using
  208.      a ``+'', ``|'', or ``,'' symbol to separate the names.  Event classes may
  209.      be excluded by using a ``-'' to separate the name.  For example,
  210.      ``network+io-disk'' indicates all network and i/o events should be
  211.      included except for disk-related events.  In addition to the above names,
  212.      a number may be used to specify a value, where the various events are
  213.      selected by bits in the value, as defined in ``<sys/rtmon.h>''.
  214.  
  215. CCCCLLLLIIIIEEEENNNNTTTT AAAACCCCCCCCEEEESSSSSSSS CCCCOOOONNNNTTTTRRRROOOOLLLL
  216.      Clients communicate with rrrrttttmmmmoooonnnndddd using a special-purpose client-server
  217.      protocol.  Requests are used to query the state of a system (e.g. the
  218.      number of processors) and to control data collection.  rrrrttttmmmmoooonnnndddd screens
  219.      service requests using a _c_l_i_e_n_t _a_c_c_e_s_s _c_o_n_t_r_o_l mechanism.
  220.  
  221.      Client access control specifies which hosts may receive service and which
  222.      events they may request collection of.  This is done using either an
  223.      ASCII file or a global specification that is given on the command line
  224.      when rrrrttttmmmmoooonnnndddd is started up.  Each control specification is of the form:
  225.           regex[:event-mask]
  226.      where _r_e_g_e_x is a regular expression that is matched against client host
  227.      names and dot addresses, and _e_v_e_n_t-_m_a_s_k is an optional specification of
  228.      the set of events that may be received (see above).  For example,
  229.      ``.*[.]sgi[.]com:all-syscall'' disallows any host in the ``.sgi.com''
  230.      domain from enabling system call tracing.  Access control files are
  231.      simply collections of access control specifications; one per line with
  232.      comments indicated by a ``#'' character (everything to the end of that
  233.      line is discarded).  rrrrttttmmmmoooonnnndddd applies the regular expressions given in a
  234.      file in the order in which they appear; the first expression that matches
  235.      the name or address of a client is used to restrict the events that can
  236.      be retrieved.  Note that if a client requests events that it is not
  237.      permitted to receive the entire request is rejected.  Any denial of
  238.      service due to an access control restriction is logged through the normal
  239.      mechanisms (typically syslog).  The ``access' trace mask can also be used
  240.      to trace other access control operations.
  241.  
  242. FFFFIIIILLLLEEEESSSS
  243.      /tmp/.rtmond_pid            server PID stash
  244.      /tmp/.rtmond_socket         UNIX domain socket for client connections
  245.      /usr/tmp/.rtmond_shm_file   shared memory file for user events
  246.      /etc/rtmond                 default client access control info
  247.      /etc/config/rtmond.options  standard system startup options and arguments
  248.                                  for rrrrttttmmmmoooonnnndddd
  249. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  250.      ppppaaaaddddcccc(1), rrrrttttmmmmoooonnnn----cccclllliiiieeeennnntttt(1), rrrrttttmmmmoooonnnn____lllloooogggg____uuuusssseeeerrrr____ttttssssttttaaaammmmpppp(3)
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.                                                                         PPPPaaaaggggeeee 4444
  261.  
  262.  
  263.  
  264.